Site acceleration with content prefetching enabled through customer-specific configurations

ABSTRACT

A CDN edge server is configured to provide one or more extended content delivery features on a domain-specific, customer-specific basis, preferably using configuration files that are distributed to the edge servers using a configuration system. A given configuration file includes a set of content handling rules and directives that facilitate one or more advanced content handling features, such as content prefetching. When prefetching is enabled, the edge server retrieves objects embedded in pages (normally HTML content) at the same time it serves the page to the browser rather than waiting for the browser&#39;s request for these objects. This can significantly decrease the overall rendering time of the page and improve the user experience of a Web site.

This application claims priority to Ser. No. 60/755,176, filed Dec. 30,2005, and Ser. No. 60/755,908, filed Dec. 31, 2005.

Portions of this application contain subject matter that is protected bycopyright.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to content delivery indistributed networks.

2. Brief Description of the Related Art

A company's Web site represents its public face. It is often the initialpoint of contact for obtaining access to the company's information ordoing business with the company. Public facing Web sites are used formany purposes. They can be used to transact commerce, where endconsumers evaluate and buy products and services, and they are oftenlinked to revenue generation and satisfying customer requests. They canbe used as news and information portals for supplying the latest contentfor consumers. A company's Web site can be used as a customerself-service venue, where customer satisfaction is critical to loyaltyin getting customers to return to the Web site. These are merelyrepresentative examples, of course. As companies place greaterimportance on the Internet, Web sites increasingly become a keycomponent of a company's business and its external communications. Assuch, the capability and flexibility of the supporting Internetinfrastructure for the Web site becomes mission-critical. In particular,the infrastructure must provide good performance for all end userconsumers, regardless of their location. The site must scale to handlehigh traffic load during peak usage periods. It must remain available24×7, regardless of conditions on the Internet. When performance,reliability, or scalability problems do occur, Web site adoption andusage can be negatively impacted, resulting in greater costs, decreasedrevenue, and customer satisfaction issues.

It is known in the prior art to off-load Web site content for deliveryby a third party distributed computer system. One such distributedcomputer system is a “content delivery network” or “CDN” that isoperated and managed by a service provider. The service providertypically provides the service on behalf of third parties. A“distributed system” of this type typically refers to a collection ofautonomous computers linked by a network or networks, together with thesoftware, systems, protocols and techniques designed to facilitatevarious services, such as content delivery or the support of outsourcedsite infrastructure. Typically, “content delivery” means the storage,caching, or transmission of content, streaming media and applications onbehalf of content providers, including ancillary technologies usedtherewith including, without limitation, DNS request handling,provisioning, data monitoring and reporting, content targeting,personalization, and business intelligence. The term “outsourced siteinfrastructure” means the distributed systems and associatedtechnologies that enable an entity to operate and/or manage a thirdparty's Web site infrastructure, in whole or in part, on the thirdparty's behalf.

FIGS. 1-2 illustrate a known CDN infrastructure for managing contentdelivery on behalf of participating content providers. In this example,computer system 100 is configured as a CDN and is managed by a serviceprovider. The CDN is assumed to have a set of machines 102 a-ndistributed around the Internet, and some or even all of these machinesmay be located in data centers owned or operated by third parties.Typically, most of the machines are servers located near the edge of theInternet, i.e., at or adjacent end user access networks. A NetworkOperations Command Center (NOCC) 104 may be used to administer andmanage operations of the various machines in the system. Third partycontent sites, such as Web site 106, offload delivery of content (e.g.,HTML, embedded page objects, streaming media, software downloads, andthe like) to the distributed computer system 100 and, in particular, to“edge” servers. Typically, this service is provided for a fee. In onecommon scenario, CDN content provider customers offload their contentdelivery by aliasing (e.g., by a DNS canonical name) given contentprovider domains or sub-domains to domains that are managed by theservice provider's authoritative domain name service. End users thatdesire such content may be directed to the distributed computer systemto obtain that content more reliably and efficiently.

The distributed computer system typically also includes otherinfrastructure, such as a distributed data collection system 108 thatcollects usage and other data from the edge servers, aggregates thatdata across a region or set of regions, and passes that data to otherback-end systems 110, 112, 114 and 116 to facilitate monitoring,logging, alerts, billing, management and other operational andadministrative functions. Distributed network agents 118 monitor thenetwork as well as the server loads and provide network, traffic andload data to a DNS query handling mechanism 115, which is authoritativefor content domains being managed by the CDN. A distributed datatransport mechanism 120 may be used to distribute control information(e.g., metadata to manage content, to facilitate load balancing, and thelike) to the edge servers. As illustrated in FIG. 2, a given machine 200comprises commodity hardware (e.g., an Intel Pentium processor) 202running an operating system kernel (such as Linux or variant) 204 thatsupports one or more applications 206 a-n. To facilitate contentdelivery services, for example, given machines typically run a set ofapplications, such as an HTTP Web proxy 207, a name server 208, a localmonitoring process 210, a distributed data collection process 212, andthe like. For streaming media, the machine typically includes one ormore media servers, such as a Windows Media Server (WMS) or Flash 2.0server, as required by the supported media formats.

The CDN may be configured to provide certain advanced content deliveryfunctionality, for example, in the case where the edge server does nothave the requested content (e.g., the content is not present, thecontent is present but is stale, the content is “dynamic” and must becreated on the origin server, and the like). In such circumstances, theedge server must “go forward” to obtain the requested content. Anenhanced CDN often provides the capability to facilitate this “goforward” process. Thus, it is known to provide a “tiered distribution”by which additional edge servers in the CDN provide a buffer mechanismto the Web site origin server. In a tiered distribution scheme, a subsetof the edge servers in the CDN is organized as a cache hierarchy, sothat a given edge server in an edge region has an associated “parent”region that may store an authoritative copy of certain requestedcontent. A cache hierarchy of this type is then controlled at afine-grain level using edge server and parent server configuration rulesthat are provided through the distributed data transport mechanism. U.S.Pat. No. 7,133,905, which is assigned to the assignee of the presentapplication, describes this scheme. Another advanced function that maybe implemented is quite useful when an edge server has to go forward toan origin server for dynamic or non-cacheable content. According to thistechnique, the CDN is configured so that a given edge server has theoption of going forward (to the origin) using intermediate CDN edgenodes instead of relying upon default BGP routing. In this function, theCDN performs tests to determine a set of alternative best paths betweena given edge server and the origin server, and it makes those pathsknown to the edge server dynamically, typically in the form of a map.When the edge server needs to go forward, it examines the map todetermine whether to go forward using default BGP or one of thealternate paths through an intermediate CDN node. This path optimizationprocess is quite useful when the content in question must be generateddynamically, although the process can be used whenever it is necessaryfor a given edge server to obtain given content from a given source.This performance-based path optimization scheme is described in U.S.Publication No. 2002/0163882, which is also assigned to the assignee ofthe present application.

BRIEF SUMMARY OF THE INVENTION

A CDN edge server is configured to provide one or more extended contentdelivery features on a domain-specific, customer-specific basis,preferably using configuration files that are distributed to the edgeservers using a configuration system. A given configuration filepreferably is XML-based and includes a set of content handling rules anddirectives that facilitate one or more advanced content handlingfeatures, such as content prefetching. When prefetching is enabled, theedge server retrieves objects (such as images and scripts) embedded inpages (normally HTML content) at the same time it serves the page to thebrowser rather than waiting for the browser's request for these objects.This can significantly decrease the overall rendering time of the pageand improve the user experience of a Web site. Using a set of metadatatags, prefetching can be applied to either cacheable or uncacheablecontent. When prefetching is used for cacheable content, and the objectto be prefetched is already in cache, the object is moved from disk intomemory so that it is ready to be served. When prefetching is used foruncacheable content, the retrieved objects are uniquely associated withthe client browser request that triggered the prefetch so that theseobjects cannot be served to a different end user. By applying metadatain the configuration file, prefetching can be combined with tiereddistribution and other edge server configuration options to furtherimprove the speed of delivery and/or to protect the origin server frombursts of prefetching requests.

The foregoing has outlined some of the more pertinent features of thepresent invention. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed invention in a different manner or by modifying theinvention as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 is a representative prior art content delivery network in whichthe present invention may be implemented;

FIG. 2 is a representative edge server of the content delivery networkof FIG. 1;

FIG. 3 is a portion of the CDN of FIG. 1 in which content prefetching isenabled according to the present invention;

FIG. 4 is a table of HTML elements that may be prefetched based onsettings in a customer-specific configuration file; and

FIG. 5 is a representative default set of metadata to enable theprefetching feature according to the present invention.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

As seen in FIG. 3, a CDN customer has off-loaded all or some of itscontent delivery requirements to the CDN service provider in awell-known manner. In this case, the CDN customer operates a site at theorigin server 316. An Internet-accessible client 300 (e.g., an end userclient machine having a browser and media player) has been directed byCDN authoritative DNS mechanism 302 to a nearby edge server 304. Thisprocess is described, for example, in U.S. Pat. Nos. 6,108,703,6,553,413 and 6,996,616. Edge server 304 may be configured as describedabove and illustrated in FIG. 2. This server includes a managementprocess that provides the content prefetching functionality of thepresent invention, as will be described in more detail below.

The given edge server 304 may be located in a set (or “region”) of edgeservers that are co-located at a given Internet-accessible data center.For convenience, only one edge server per region is shown. Contenthandling rules are configured into each edge server, preferably via ametadata configuration system 306. As shown, the configuration systemprovides edge server content control metadata via links 318, whichthemselves may include other infrastructure (servers, and the like).U.S. Pat. No. 7,111,057 illustrates a useful infrastructure fordelivering and managing edge server content control information, andthis and other edge server control information can be provisioned by theCDN service provider itself, or (via an extranet or the like) thecontent provider customer who operates the origin server 316. Ifconfigured appropriately, given subsets of edge servers, such as edgeservers 304 and 310, may comprise a cache hierarchy so that edge server304 may “go forward” to a CDN parent instead of to the origin server asneeded. This tiered distribution is described in U.S. Pat. No.7,133,905, as noted above. Also, if configured appropriately, the CDNmay provide overlay path routing to enable the edge server 304 to goforward to the origin server 316 through an alternate CDN path, such asthe path through edge server 308, or through edge server 312, dependingon whether one of these alternative paths provides better performancethan a default BGP path. As noted above, this performance-based overlaypath delivery scheme is described in U.S. Publication No. 2002/0163882.The disclosures of each of the above-identified references areincorporated herein by reference. As also seen in FIG. 3, an edge server314 may be co-located with the customer origin server, although this isnot required.

According to the present invention, a given CDN edge server isconfigured to provide one or more extended content delivery features. Tothis end, the CDN edge servers are configurable to provide thesedelivery features on a customer-specific, customer domain-specific,preferably using XML-based configuration files that are distributed tothe edge servers using a metadata configuration system such as describedabove. A given XML-based configuration file includes a set of contenthandling rules and directives that facilitate one or more advancedcontent handling features. Thus, for example, when an edge servermanagement process receives a request for content, it searches an indexfile for a match on a customer hostname associated with the request. Ifthere is no match, the edge server process rejects the request. If thereis a match, the edge server process loads metadata from theconfiguration file to determine how it will handle the request. Thus,for example, the metadata for the hostname may indicate whether to servethe request from cache or from the origin. If the metadata indicatesthat the request is associated with cached or cacheable content, theinformation may then direct the edge server to look for the content in alocal cache or, failing that, to fetch the content from a CDN cachehierarchy parent node. If content is cacheable, the metadata mayinstruct the edge server process to apply given content handlingdirectives. One such set of directives implement a content prefetchfunction, which will be explained in detail below. If, on the otherhand, the configuration file indicates that the edge server should goforward to handle the request (because, e.g., the request involves atransaction that must occur at the origin server) the metadata mayindicate how the edge server should go forward, e.g., using pathoptimization to try to reach the origin using intermediate CDN paths.Other metadata may control how a given edge server establishes andmaintains connections with one or more other edge servers or othermachines, or how the edge server should deliver the content to therequesting end user browser once it has been obtained. In any event, aset of content handling directives are set forth in the XMLconfiguration file for a given customer domain and used to control theedge server to provide these advanced functions.

As noted above, in one embodiment, an XML-based configuration filecontrols an edge server to provide an enhanced content deliveryfunction, namely, content prefetching, on a per-customer, per customerdomain-basis. Using this service, a given CDN customer can set up(directly or with the assistance of the CDN service provider) an edgeserver handling configuration for all or part of the customer's Web siteor other content to be delivered over the CDN. A participating contentprovider can be a formal Web publisher, or the content in question canbe user-generated content (UGC). In a typical use scenario, the edgeserver is shared among participating content providers, and one or moreof such providers establish a prefetching configuration (by default, oras a custom configuration) that is enabled and enforced on the edgeserver. Thus, for example, when prefetching is enabled, the edge serverretrieves images and scripts embedded in pages (normally HTML content)at the same time it serves the page to the browser rather than waitingfor the browser's request for these objects. This operation cansignificantly decrease the overall rendering time of the page andimprove the user experience of a Web site.

Although the remainder of this description focuses primarily on thecontent prefetching capability, one of ordinary skill in the art willappreciate that, by using XML-based configurations, this function can becombined readily with other edge server functions that are also definedin such customer-specific, domain-specific configurations. Thesefunctions include, without limitation, path optimization (e.g., fornon-cacheable or dynamic content), client-server (e.g., edgeserver-to-edge server) TCP connection optimizations, contentcompression, and the like. Path optimization, as described in U.S.Publication No. 2002/0163882, the disclosure of which is incorporated byreference, significantly decreases latency when the edge server has togo forward to the origin (or other source), which is often required tofacilitate transactions (or other occurrences) that call for dynamiccontent generation. TCP connection optimization involves adjusting oneor more TCP settings (e.g., congestion window size, retransmit timeout,packet reordering, and the like), which reduces edge server-to-edgeserver communication latency, as does content compression.

The following describes a content prefetching enhancement.

As will be seen, prefetching can be applied to either cacheable oruncacheable content. When prefetching is used for cacheable content, andthe object to be prefetched is already in cache, the object is movedfrom disk into memory so that it is ready to be served. When prefetchingis used for uncacheable content, the retrieved objects are uniquelyassociated with the client browser request that triggered the prefetchso that these objects cannot be served to a different end user. Byapplying metadata in the configuration file, prefetching can be combinedwith tiered distribution to further improve the speed of object deliveryand to protect the origin server from bursts of prefetching requests.

In one embodiment, the following restrictions apply when determiningwhether to scan a response body for prefetchable content or to prefetcha referenced object: the edge server applies prefetching only toresponses with a content-type header that begins with certain extensions(e.g. text/html, or some other given format), only responses with HTTPstatus codes of 200 or 404 are scanned for prefetchable objects; objectsto be prefetched are referenced using the same protocol (HTTP or HTTPS)as the client used to request the original page; and object referencesuse the same hostname as the original request.

The following provides a more detailed description of the prefetchingfeature including descriptions of the request flow, the conditions forscanning the base page, the content of prefetch requests, andcomposition of the browser-ID for uncacheable content. By way ofbackground, without prefetching, the edge server requests content fromthe origin server (or a parent edge server) only when it receives arequest for the content from an end client (browser). This means thatimages referenced by a page are not retrieved until the end user'sbrowser has received and read the page and requested those images. Thenormal request flow is as follows: the browser requests the page fromthe edge server, the edge server retrieves the page from cache (or fromthe origin server if the page is not already in cache), the edge serverreturns the page to the browser, the browser scans the contents of thepage and requests the objects referenced by the page, the edge serverretrieves the images and other content from cache (or from the originserver if the objects are not already in cache), and the edge serverreturns the requested objects to the browser. With prefetching enabled,however, the edge server actively scans the page for embedded images andscripts and retrieves these objects before they are requested by theend-user's browser. The new request flow is as follows. The end-userclient requests a page from the edge server; the edge server retrievesthe page from cache (or from the origin server if the page is notalready in cache). The edge server then scans the page (usually HTML)for referenced images and scripts at the same time it serves the page tothe browser. Note that it is not required that every response isscanned. The conditions that determine whether a response is scanned aredescribed below. Now, overlapping in time, the following events occur:the edge server retrieves the referenced images and scripts from cache(or from the origin server if the objects are not already in cache), andthe browser scans the page and requests the objects referenced by it.The edge server returns the requested objects to the client browser.

Preferably, when prefetching is used, the edge server scans appropriateresponses from the origin. Not every response is required to be scanned.The edge server scans the response and begins prefetching embeddedobjects if one or more of the following conditions are true (andpreferably all of them must be): a prefetching status is “on” for thisrequest, an HTTP status code of the response sent to the client is 200or 404, a response content-type starts with one of a set of configuredstrings (by default, the edge server scans the response only if thecontent type starts with text.html), no preset limit (a configurablethreshold) on an average number of prefetch requests per unit time hasbeen reached, a prefetch-on-hit metadata tag is “on” if the page isalready in cache, an indirect-only metadata tag is “off” if the edgeserver is an edge server that connects directly to the origin, apush.status metadata tag is “off” if the edge server is connecting to acache hierarchy parent, and the edge server received a special requestheader from a child peer (that reads X-Cdnsp-Prefetch:type=push-to-edge)if the edge server is a cache hierarchy parent.

When the edge server identifies a response that should triggerprefetching, it parses the page (usually HTML) as it sends the responseto the client. Each time the edge server encounters a tag in the pagethat is a candidate for prefetching (with two exceptions noted below),it creates a dummy request for the URL for this object and appliesmetadata to the request. Preferably, this is done only for the firstinstance of an object reference, so that multiple references to the sameobject within the page do not result in multiple requests for thatobject. The following are several possible settings for scanning a page:scan using an HTML processor (which treats the entire page as SGML andscans for URLs contained in specific elements as listed below); scanusing a regular expressions processor (this treats the entire page asplaintext and uses regular expression rules to identify links toprefetch), and/or scan using the HTML processor for the defined tags,using a regular expressions processor on the <script> elements toidentify URLs within JavaScript sections. By default, HTML elements thatgenerate candidates for prefetching are <IMG> and <SCRIPT>, althoughoptionally a given configuration file can be used to configureprefetching of objects referenced by any of the elements listed in thetable in FIG. 4. Any type of content object may be prefetched and notjust images and scripts. After metadata is applied to the dummy objectrequest, the edge server decides to prefetch an object if the followingare true: prefetchable-object metadata is “on” for this object, theobject is not found in cache (if the object is found in cache,preferably it is moved to a hot object cache), and no prefetching limithas been reached. In an alternative embodiment, a regular expressionparser in the edge server allows scanning of any text file for prefetchcandidate URLs. This is particularly useful when the response isJavaScript. If the regular expressions processor is used, theconfiguration file must enclose the metadata within a match on a givencontent-type or file extension of the object to avoid having thesesettings apply to other parsing. Using the configuration file, it isalso possible to define regular expression rules for selecting URLswithin the JavaScript sections of an HTML page. This can be done bydefining the regular expression matching rules in the configuration filebut then leaving the processor type set to HTML; this will cause all<script> sections in the HTML to be scanned with the regular expressionsprocessor.

As noted above, when the page is scanned for prefetch candidates, anexception may prevent an otherwise qualified URL from being prefetched.For example, in one embodiment, an exception that may cause an object tobe skipped is that the object's URL does not have the same hostname asthe base page. Another possible exception is that protocol (HTTP orHTTPS) of the embedded object reference is not the same as the requestthat triggered the prefetch. This is not a limitation of the prefetchingfunctionality of the invention, however, as in certain circumstances itmay be desired to allow the edge server to prefetch objects fromdifferent hostnames, or if a protocol match is not present.

When the edge server creates the requests to prefetch embedded objects,the request typically contains a number of components. These include,for example, a header X-Cdnsp-Prefetch-Object, which is used to preventthese requests from triggering further prefetching. The headerpreferably is also sent to the origin, and it may include a currentlevel of recursion when recursive prefetching is enabled (as describedbelow). The request may also include the request headers from the basepage (including all cookies, regardless of whether the path specifiedfor a cookie matches the path for the embedded object). Preferably, therequest also includes cookies created from any Set-Cookie headers in theresponse page, where the domain of the Set-Cookie matches the hostnamefor the request. Preferably, the edge server ignores path and secureparameters of the Set-Cookie headers. If necessary, using theconfiguration file the edge server can be controlled to select whichcookies are used in the prefetch request. By default, preferably allcookies and Set-Cookies that match the hostname are included, althoughmetadata can be set to include or ignore cookies by name.

By default, when prefetching is enabled, the edge server will prefetchobjects that are non-cacheable along with those that are cacheable. Theserver may also prefetch objects that have a zero second TTL assigned tothem. In such case, preferably the edge server holds these objects in aseparate buffer; they expire after a short time, can be served onlyonce, and can be served only to the same user that requested the pagethat references them (e.g., based on the browser-ID). Further,preferably the edge server can prefetch two kinds of non-cacheableobjects: objects with “no-store” or “bypass-cache” metadata, and objectsthat are non-cacheable based on their response headers (for example, aVary: header). Using metadata in the configuration file, however, theedge server can be configured to not prefetch no-store or bypass-cachecontent and not store uncacheable objects that were prefetched. This maybe useful when prefetching is used in combination with path optimization(for dynamic content) as will be described below.

If desired, the browser-ID buffer may include cacheable objects withvery short TTLs. This may be desirable if a TTL is only a few seconds,and the number of objects included in an HTML page is large enough toprevent the browser from requesting those objects before then expire incache. If a prefetched object's TTL expires before the browser requestsit, the edge server must re-request the object when the browser requestfinally arrives, and the benefit of prefetching is lost for this object.When the browser-ID is applied to objects with short TTL's, preferablythey are handled just like uncacheable objects. In particular, theyexpire after a short time, can be served only once, and can be servedonly to the same user that requested the page that references them.

When a user requests a page and objects are prefetched, the objectspreferably are associated with a “browser-ID” that uniquely identifiesthe user. In one embodiment, the edge server computes a “browser-ID”based on the IP address, cookies, and request headers of the userrequest. By default, all cookies are used in the computation along withthe User-Agent and Authorization headers. Special rules may be appliedfor users behind proxies or with no user session cookies, as in suchcase there is no guarantee the browser-ID will identify a unique user.In one embodiment, the browser-ID is a value that is generated byapplying a given function to a concatenation, e.g., the IP address ofthe browser (as seen by the edge server), a hash calculated over one ormore cookie values, and a hash of one or more header values.

Generally, when a browser requests content from a domain, it will openonly a few connections to the server and make its requests across thatlimited number of connections. An edge server does not limit its forwardconnections the way a browser does. Preferably, the edge servermaintains persistent connections, and it reuses those establishedconnections as they are available. If there are more requests to satisfythen there are connections available, the edge server preferably opensnew connections. It relies on the origin server to limit the number ofconnections. If an edge server performed prefetching for an HTML pagethat contained many references to content not in the edge server'scache, that edge server could attempt to open many connections with theorigin server. If this occurred across the network of edge serverssimultaneously, the origin server could be overloaded with requests fromthe edge servers. To avoid this problem, preferably some degree of ratelimiting is applied to the prefetching functions. To this end, there isa set of metadata tags for limiting the number of prefetch requests thatcan be in process to the origin (or other) server at one time. Thesetags control the time period over which to measure the average number ofrequests, an upper bound for prefetch requests in process (beyond thispoint prefetch requests are blocked), a lower bound for prefetchrequests in process (after prefetching has been blocked, it can restartonce the number of requests in process drops to this level), a maximumnumber of URLs to scan for prefetching within a single page, and amaximum number of prefetch requests to generate for a single page.

The above description of the prefetching function has assumed that theobjects referenced within the base page do not themselves containprefetchable objects. This is not always the case. For example, an HTMLpage could include another HTML section through use of an <iframe>tag,and the included HTML might make reference to an image. In this case,the base page cannot be fully rendered by the browser until the secondHTML section and its embedded image have both been fetched. For caseslike this, it might be advantageous to prefetch recursively. That is, toprefetch objects referenced by prefetched HTML. Using the configurationfile settings, recursive prefetching can be enabled, includingcontrolling how many level of prefetching are performed. The recursionfeature can also be set to be used only on URLs found in HTML tags thatdefine links (i.e., A, AREA, LINK or FORM tags), as it is not desirableto prefetch links recursively.

It may also be desirable to prefetch when tiered distribution is enabledbetween edge server regions. To this end, a request headerX-Cdnsp-Prefetch is used between cache hierarchy edge server peers. Whenprefetching is done from an edge server process to a parent edge server,the value of the header is X-Cdnsp-Prefetch: type=pull-from-edge. Incontrast, when the prefetching is done from the parent edge serverprocess, the value of the header is X-Cdnsp-Prefetch: type=push-to-edge.Push-to-edge prefetching typically is not used by default. When enabled,however, the parent edge server process issues an Cdnsp_PREFETCH_PUSHrequest to a requesting edge server process as soon as the responsecomes in to the parent edge server. The protocol (HTTP or HTTPS) is thesame as for the embedded object. The request includes request headersthat are sent as early as possible (preferably even before the parentedge server goes forward for the embedded object). The response headersand body of the prefetched object are sent as soon as the parentreceives them from the origin. In the event the parent edge serverdecides to abort the request, it sends an HTTP 500 response to the edgeserver, which will preserve the persistent connection. Preferably, theserequests always use persistent connections (i.e., they either have abody content-length or use chunking, and they do not get closed by theedge server process). Also, preferably the edge server processesinvolved in such prefetching authenticate one another to preventmalicious users from forcing arbitrary objects into the edge servercache. The Cdnsp_PREFETCH_PUSH request also may contain a line withX-Csnsp-Prefetch-Browser-ID. The PUT body of this request contains firstthe response headers from the original object, then the response body.After the edge server process parses the request headers, it will “plug”the parsing of the rest of the response on the already existing code onthe forward side.

According to a feature of the present invention, a given CDN customercan establish a custom prefetching configuration for given site or othercontent, preferably using an XML-based configuration file that isdelivered to and used by a given edge server to implement a prefetchingdirective. Typically, the same configuration file is delivered to all ofthe edge servers, and this configuration file may be changed dynamicallyusing the metadata configuration system.

A configuration file includes directives that identify the appropriatecontent for prefetching and how the feature should be enabled for thatcontent. The following section provides additional detail regarding themetadata related to configuring the prefetch feature. Preferably, allmetadata used for prefetching starts with a given tag such asedgeservices:prefetch. While there are many metadata tags for use intuning the configuration, most of these tags are not necessary in thecustomer's configuration file, as default settings (as described below)may be adequate. A minimal set of metadata to enable prefetching for agiven content provider domain is shown in FIG. 5. The meaning of thismetadata (among other prefetching directives) is described below.

In particular, the following is representative list of prefetchmetadata:

Preferably, prefetching is enabled through a single metadata tag:

<edgeservices:prefetch.status>on</edgeservices:prefetch.status>

As noted above, when this metadata applies to a request, thecorresponding response will be scanned for prefetchable objects if theresponse has an HTTP 200 or a 404 status code and a Content-Type headerthat begins with “text/html” or other content types defined inedgeservices:prefetch.content-types.

By default, only responses of type “text/html” are scanned forprefetchable objects. Other content types can be added using thefollowing tag. Note that a wildcard should be used if the content-typeheader contains more than the simple type definition. The tag takes aspace separated list of content-type strings:

<edgeservices:prefetch.content-types>text/html*</edgeservices:prefetch.content-types>

By default, preferably the edge server scans responses using an SGMLparser to identify HTML tags that contain candidate URLs forprefetching. As described, it may be desired to scan the page asplaintext using a regular expression parser. Thus, to scan the responseas plaintext using a regular expressions parser, the parser-type is setto regex using the following tag:

<edgeservices:prefetch.parser-type>regex</. . . >

In the above case, a regular expression processor is turned on and isprovided a list of rules. In particular, if it is desired to scan eitherthe entire page or the JavaScript sections of an HTML page using regularexpressions, a set of regular expression rules are defined for theparser to use. Whenever parser-type is set to regex the entire page isscanned using these rules. If the parser-type is set to html the rulesare used only within the <script> tags, and the rest of the page body isscanned using the SGML processor. Note also that regardless of theparser type setting, the content-type of the response must be listed inthe prefetch. content-types tag for the edge server to parse theresponse. Preferably, these tags are inside a match on the responsecontent-type, or inside a match on uri extension of the object, whereinPrefetch.regex.rule is a listable tag set that contains aperl-compatible regular expression along with a string and flags:

<edgeservices:prefetch.regex>  <status>on</status> <rule>#&1g;img\s+src\s+=\s+[\‘\“]?(.*?)[\’\”]?&gt;#$1#gi</rule></edgeservices:prefetch.regex>

The following metadata tag indicates whether or not an object isprefetchable. This tag should be set explicitly, as the default valuepreferably is off:

<edgeservices:prefetch.prefetchable-object>on</edgeservices:prefetch.prefetchable-object>

If this flag is on, no prefetching occurs if the edge server goesdirectly to the origin:

<edgeservices:prefetch.indirect-only>off</edgeservices:prefetch.indirect-only>

If a prefetch-on-hit flag is off, the edge server does not prefetch ifthe request for the HTML is a hit (an in-memory hit, an ICP hit, or anIMS hit). If the flag is on, the edge server prefetches from cached HTML(i.e., the server goes forward for non-cached or expired objects, andmoves cached objects from disk into hot object cache). If the cache hithappens on the edge server, then the prefetching is done from the edgeserver even if push.status is true (because the parent would not get anyrequest):

<edgeservices:prefetch.prefetch-on-hit>off</edgeservices:prefetch.prefetch-on-hit>

A prefetch-on-304 flag controls whether the edge server will prefetch ifthe response to the client is an HTTP 304. The default is “off,” so theserver will scan the page and prefetch embedded objects only when theresponse to the client is an HTTP 200 for the base page. If this flag ison, the edge server also prefetches when a 304 is returned to theclient. When this flag is on, prefetch-on-hit should be on as well:

<edgeservices:prefetch.prefetch-on-304>off</edgeservices:prefetch.prefetch^(-on-)304>

By default, the edge server will prefetch after processing dynamiccontent assembly (DCA) requests. This means that only objects that arereferenced in the HTML response served to the client browser areactually prefetched. If it is desired to prefetch all objects referencedseparately by DCA fragments and containers, the following tag preferablyis turned off:

<edgeservices:prefetch.after-dca>off</edgeservices:prefetch.after-dca>

When the browser-id status flag is on (the default setting), the edgeserver temporarily keeps prefetched non-cacheable objects (and objectswith a zero-second TTL) in memory. These objects are associated with theuser's browser-id, and they can only be served once. The non-cacheableobjects preferably preferably are never stored on disk:

<edgeservices:prefetch.browser-id.status>on</edgeservices:prefetch.browser-id.status>

When prefetching non-cacheable content, the browser-ID can be calculatedusing a default calculation, or a set of metadata tags can be used todefine what components (e.g., IP address mask size, cookies and headers)are used for the calculation.

A fetch separator controls the actual retrieval of content throughprefetching using metadata tags that are now described.

In particular, a first tag is used to define a list of cookies that getsent to the origin when the edge server prefetches embedded objects. Bydefault, the list is *, so all cookies are sent. Preferably, the edgeserver also takes into account the “Set-Cookie” headers from the HTMLresponse:

<edgeservices:prefetch.fetch.pass-cookies>*</edgeservices:prefetch.fetch.pass-cookies>

A second tag is used to define a list of cookies that do not get sent tothe origin when the edge server prefetches embedded objects. By default,this list is empty:

<edgeservices:prefetch.fetch.ignore-cookies>(empty)</edgeservices:prefetch.fetch.ignore-cookies>

The following tag is used to define a maximum number of distinct URLsthe edge server will consider prefetching inside the HTML page. For eachURL, the edge server creates a request object, applies metadata, checksthat the prefetchable-object flag is set, checks that the object is notalready in memory, and then fetches it if necessary:

<edgeservices:prefetch.fetch.max-urls-per-page>20</edgeservices:prefetch.fetch.max-urls-per-page>

The following tag is used to define a maximum number of embedded objectsfor which the edge server is going forward:

<edgeservices:prefetch.fetch.max-prefetches-per-page>15</edgeservices:prefetch.fetch.max-prefetches-per-page>

The following tag is a space-separated list of HTML elements. Thepossible values are A, IMG, SCRIPT, FRAME, IFRAME, LINK, OBJECT, AREA,APPLET, EMBED, INPUT, OFORM, BODY, TABLE, TD, TH, BASE and INCLUDE. Thisis just a representative list, and the list may be expanded to includeany tags that can reference external objects. Preferably, the edgeserver only considers prefetching objects inside these elements:

<edgeservices:prefetch.fetch.html-elements>SCRIPTIMG</edgeservices:prefetch.fetch.html-elements>

When the HTML returned to the user is compressed, the edge server mustunzip it internally to parse it. If the following flag is on, the serverwill not try to uncompress the HTML and therefore will not be able toprefetch the embedded objects.

<edgeservices:prefetch.fetch.donot-uncompress>off</edgeservices:prefetch.fetch.donot-uncompress>

By default, objects can only be prefetched from the same domain asappeared in the request for the HTML page; this restriction can berelaxed by using the following tag:

<edgeservices:prefetch.fetch.allow-same-map>off</edgeservices:prefetch.fetch.allow-same-map>

When this flag is “on” prefetching will be allowed from domains otherthan the domain of the original request for the HTML, provided (forexample) that those domains use the same CDN map. For example, if theclient requests a page from html.example.com and that page containsreferences to images at images.example.com, and both these domains arealiased (through a DNS CNAME) to axxx.g.cdnsp.net then the prefetchrequests can go forward. When the map comparison is performed, anidentifier (e.g., a serial number) in the map name (represented by xxxabove) is relevant, and only prefetch requests that use the same serialnumber are allowed to go forward. The edge server can allow prefetchrequests regardless of the serial number in the map name by turning offthe tag:

<edgeservices:prefetch.fetch.serial-must-match>off</edgeservices:prefetch.fetch.serial-must-match>

This metadata is used to define a maximum number of objects the edgeserver will try to prefetch without going back to a main processing loop(no prefetching):

<edgeservices:prefetch.fetch.urls-before-yield>5</edgeservices:prefetch.fetch.urls-before-yield>

The edge server will stop loading embedded objects from disk after itreads more than a threshold set by the following metadata:

<edgeservices:prefetch.fetch.disk-abort-threshold>10KB</edgeservices:prefetch.fetch.disk-abort-threshold>

The edge server will stop loading embedded objects from the networkafter it reads more than a threshold set by the following metadata (thiswill close the forward connection if no user request has been receivedyet):

<edgeservices:prefetch.fetch.network-abort-threshold>1MB</edgeservices:prefetch.fetch.network-abort-threshold>

Recursive prefetching is enabled with the tags in the “recursion”selector:

<edgeservices:prefetch.recursion>

The number of levels of prefetching is controlled by the tag:

<edgeservices:prefetch.recursion.depth>1</ . . . >

This tag specifies a maximum allowed depth for recursive prefetching. Adefault value is “1,” which means that recursive prefetching isdisabled. A minimum value is “1,”, and the absolute maximum value is“5.” Preferably, the value “0” is not valid; to disable prefetching, the<prefetch.status> tag is set to “off” instead. When performing recursiveprefetching on SGML content (i.e., with the parser-type tag set toHTML), recursive prefetching can be applied to tags that define linksusing the following tag:

edgeservices:prefetch.recursion.allow-link-recursion>off</. . . >

A default value is “off” When this tag is off, recursive prefetchingdoes not apply to HTML tags that define links, i.e., preferably tags A,AREA, LINK, FORM are prefetched at a first level (the client-requestedHTML) if declared in the list of tags to prefetch but are not prefetchedat the recursive levels below. For example, when this tag is “off,” theedge server will not recursively prefetch objects embedded in <a href= .. . >, but will recursively prefetch objects embedded in <frameset src=. . . >. If the tag is set to “on,” the edge server will recursivelyprefetch from the link tags as well as the object references. When theedge server makes a forward request to prefetch an object, it adds therequest header X-Cdnsp-Prefetched-Object. The value preferably is acurrent level of recursion (starts at 1, and goes until<recursion.depth>).

The following metadata is used to apply rate limiting to prefetchrequests. It can restrict prefetching based on either or both the rawnumber of requests (the “count”) and the amount of bandwidth therequests have used (the “bandwidth”). Further, the metadata can be setfor specific types of prefetch requests (for example, requests to theorigin) or for “all” prefetch requests:

<edgeservices:prefetch.fetch.rate-control>  <status>on</status> <type></type>  <high-count>0</high-count>  <low-count>0</low-count> <high-bandwidth>0B</high-bandwidth>  <low-bandwidth>0B</low-bandwidth> <time-scale>30s</time-scale></edgeservices:prefetch.fetch.rate-control>

The high-bandwidth tag specifies the point at which rate limiting willbe applied based on bandwidth usage of the prefetch requests. Thehigh-count tag specifies the point at which rate limiting will beapplied based on the number of prefetch requests of the given type. Oncerate limiting has been applied to prefetch requests based on theirbandwidth consumption, the low-bandwidth tag is the point at whichprefetching can resume. When the bandwidth consumption drops to thislevel, new prefetch requests can be generated. Once rate limiting hasbeen applied to prefetch requests based on their number, the low-countis the point at which prefetching can resume. When the number ofoutstanding prefetch requests drops to this level, new prefetch requestscan be generated. The status tag controls whether the prefetch ratelimiting feature is used. The time-scale tag defines the time scale overwhich the moving average of prefetch requests (count) or bytes used(bandwidth) are measured. So, for example, with the default setting, ifthe high-count number of prefetch requests were generated in 30 seconds,no more requests could be generated until the low-count number ofprefetch requests was reached within a 30 second measurement window. Thetype tag specifies the type of request for which rate controls should beimposed. Valid values may include all (applies to all prefetch relatedrequests, and no other separate rate control settings apply), disk(requests resulting in a disk hit), cache-h (requests resulting incache-h or path optimization fetch or push), and origin (requestsresulting in a forward request to the origin).

To enforce fetch limits when the edge server goes forward forprefetching, the following tags can be used:

<edgeservices:prefetch.fetch.limits.status>on</edgeservices:prefetch.fetch.limits.status>

Preferably, these limits are based on the number of prefetch requestsper forward hostname, and they are available to be overridden at thelevel of customer configuration. Also, preferably only prefetch requeststhat must go forward to the origin are counted against the limit.

The edge server will stop prefetching if the average number ofprefetching requests per second reaches this watermark. A value of 0means that there is no watermark:

<edgeservices:prefetch.fetch.limits.requests-high-watermark>10</edgeservices:prefetch.fetch.limits.requests-high-watermark>

Once fetch limits have been imposed, the edge server will stopprefetching until the average number of prefetching requests per secondreaches this threshold. This setting should never be zero when limitsare applied, otherwise the server could stop prefetching for aconsiderable period of time:

<edgeservices:prefetch.fetch.limits.requests-low-watermark>5</edgeservices:prefetch.fetch.limits.requests-low-watermark>

The edge server will stop prefetching if the average number of bytes persecond reaches this threshold. A value of 0 means that there is nowatermark:

<edgeservices:prefetch.fetch.limits.bandwidth-high-watermark>100KB</edgeservices:prefetch.fetch.limits.bandwidth-high-watermark>

Once fetch limits have been imposed, preferably the edge server willstop prefetching until an average number of bytes per second reachesthis threshold. This setting should never be zero when limits areapplied, otherwise the server could stop prefetching for a considerableperiod of time:

<edgeservices:prefetch.fetch.limits.bandwidth-low-watermark>80KB</edgeservices:prefetch.fetch.limits.bandwidth-low-watermark>

The following metadata is the time scale used in the computation of theexponentially-weighted moving average for the number of requests persecond and for the bandwidth. The larger it is, the slower the movingaverage will vary:

<edgeservices:prefetch.fetch.limits.time-scale>30s</edgeservices:prefetch.fetch.limits.time-scale>

The following metadata describes how to control the “push-to-the-edge”function. If this flag is on, the prefetching type between edge serversin a cache-hierarchy configuration is “push-to-the-edge.” Otherwise, itis “pull-from-the-edge.” This flag is ignored if the edge server goesdirectly to the origin:

<edgeservices:prefetch.push.status>Off</edgeservices:prefetch.push.status>

The following is the baseline tag used to disable all “push” code (bothclient and server side):

<edgeservices:prefetch.push.enable>on</edgeservices:prefetch.push.enable>

When a “push” race condition happens (in other words, when the browserrequest for an embedded object comes in before the child edge serverreceives the “pushed” object from its parent), the server will close theconnection to the second response (therefore losing the persistentconnection) if its size is bigger than a threshold set by this tag:

<edgeservices:prefetch.push.close-response-size-threshold>200KB</edgeservices:prefetch.push.close-response-size-threshold>

This baseline tag is used to disable the prefetching feature globally ifnecessary. The default value is on:

<edgeservices:prefetch.enable>on</edgeservices:prefetch.enable>

This baseline tag is used to temporarily stop prefetching if a givenedge server CPU utilization percent is above this threshold:

<edgeservices:prefetch.percent-threshold>90</edgeservices:prefetch.percent-threshold>

This is a baseline tag that defines a maximum number of objects to keepin the edge server cache for non-cacheable prefetched objects:

<edgeservices:prefetch.cache.max-objects>1000</edgeservices:prefetch.cache.max-objects>

This is a baseline tag that defines a maximum total size of the cachefor non-cacheable prefetched objects:

<edgeservices:prefetch.cache.max-total-size>10MB</edgeservices:prefetch.cache.max-total-size>

This is a baseline tag that defines how long to keep non-cacheableprefetched objects:

edgeservices:prefetch.cache.max-lifetime>1m</edgeservices:prefetch.cache.max-lifetime>

If desired, prefetching can be combined with other edge server features,such as path optimization, TCP connection optimization, contentcompression optimizations, and the like.

Thus, for example, to enable path optimization, the customer-specific,domain-specific configuration file may include a path optimizationdirective such as the following:

<forward:cache-parent>  <status>on</status> <selection-method>SR</selection-method>  <policy>performance</policy> <map>example.map.cdnroute.cdnsp.com</map> <SR.max-parents>2</SR.max-parents> </forward:cache-parent>

In this example, the status attribute turns the function on for thedomain, and the selection-method sets the method by which the edgeserver identifies its parents. When set to SR, the edge server uses themap name and the max-parents to form a hostname that resolves throughDNS to the appropriate IP addresses of the alternative edge servers thatare used for the go forward request. Thus, for example, the policy setsthe order in which the edge server will contact the cache parents. Whenset to performance the edge server will use test object races to orderthe parents and the origin based on the speed of responses to a set ofrace requests. The map sets the base hostname the edge server will useto construct the final hostname it looks up in DNS. The max-parentsattribute sets how many indirect routes the edge server will use. Theseare representative settings.

To enable edge server-to-edge server (or other client-server) TCPoptimizations, the following metadata can be set in the configurationfile, once again on a customer-specific, domain-specific, basis. Inparticular, the controls for changing the TCP settings are in aseparator: network:tcp.transport. Within this separator, preferablythere are two listable nodes, one to control the settings that are basedon a size (and thus can take an integer as a value) and the other tocontrol timeout setting (which takes a “delta time” as a value). Thenodes may include:

network:tcp.transport.size

network:tcp.transport.timeout

Preferably, the structure of these nodes is the same. They each containa status (to turn the node on or off, a parameter (the name of theparameter to be set), a direction (to define which connection thissetting will control), and a value (the value to set for the parameter).The parameter may be one of: cwnd_init (initial congestion window),cwnd_ssinc (slow start increase), cwnd_cainc (congestion avoidancerate), cwr_dec (congestion reduction rate), and many others. Thedirection defines which connection this setting will control. Thepossible values are: edge-to-user, edge-to-origin, edge-to-parent, andedge-to-child. Thus, the following metadata illustrates how to adjustthe TCP settings used for edge server-to-edge server communication. Thefirst setting is for the edge-to-child direction, and it adjusts theinitial congestion window. The initial congestion window is alsoadjusted for the edge-to-parent direction so that the child advertisesan appropriately large window and can use that larger window for POSTtransactions:

<network:tcp.transport.size>  <status>on</status>  <value>6</value> <parameter>cwnd_init</parameter>  <direction>edge-to-child</direction></network:tcp.transport.size> <network:tcp.transport.size> <status>on</status>  <value>6</value>  <parameter>cwnd_init</parameter> <direction>edge-to-parent</direction> </network:tcp.transport.size>

The following metadata can be included in the configuration file tofacilitate content compression (e.g., from the edge server to thebrowser):

<edgeservices:lastmileacceleration.edge-browser>on<.../edgeservices:lastmileacceleration.edge-browser>    <match:response.header.

The various edge server routines that manage the metadata tag handlingare implemented in software running on commodity hardware.

Having described our invention, what we claim is as follows.
 1. In anedge server in a content delivery network that is shared by a set ofparticipating content providers, wherein a given content provideridentifies given content for delivery, a method of content delivery,comprising: as a given object associated with a content provider domainis being served to a requesting client, scanning the given object if aprefetching status for the content provider domain has been enabled anda given prefetch limit has not been exceeded; and prefetching a contentobject associated with the given object.
 2. The method as described inclaim 1 wherein the scanning step is initiated if a content-typeassociated with the given object has a given value.
 3. The method asdescribed in claim 1 wherein the scanning step is initiated if aresponse code associated with the given object has a given value.
 4. Themethod as described in claim 1 wherein the given prefetch limit is oneof: a number of prefetch requests, and an amount of bandwidth usageassociated with the prefetch requests.
 5. The method as described inclaim 4 wherein the number of prefetch requests has a first thresholdvalue at which prefetching is stopped, and a second threshold value atwhich prefetching, once stopped, is reinitiated.
 6. The method asdescribed in claim 4 wherein the amount of bandwidth usage associatedwith the prefetch requests has a first threshold value at whichprefetching is stopped, and a second threshold value at whichprefetching, once stopped, is reinitiated.
 7. The method as described inclaim 4 further including setting a time-scale over which the givenprefetch limit is evaluated.
 8. The method as described in claim 1wherein the content object is cacheable.
 9. The method as described inclaim 8 wherein the prefetching step further includes: determiningwhether the content object is already cached on disk in the edge server;and if the content object is already cached on disk in the edge server,moving the content object from disk to memory.
 10. The method asdescribed in claim 1 wherein the content object is non-cacheable. 11.The method as described in claim 10 further including the step ofconfiguring a unique identifier to prevent the content object from beingdelivered to any entity except the requesting client.
 12. The method asdescribed in claim 1 wherein the content object includes at least oneprefetchable object associated therewith, and the method furtherincludes the step of performing a prefetching operation on theprefetchable object associated with the content object.
 13. The methodas described in claim 1 wherein the content object has a domain that isthe same as the content provider domain or different from the contentprovider domain.
 14. The method as described in claim 1 wherein thecontent object is fetched from one of: an origin server, and a parentedge server.
 15. Apparatus that is shared by a set of participatingcontent providers, wherein a given content provider has an associatedorigin server and identifies given content for delivery, comprising: aprocessor and an associated operating system; a proxy server; a datastore in which is stored a customer-specific, domain-specificconfiguration file that includes a set of one or more contentprefetching directives; and code executable in the processor to prefetchone or more content objects associated with a given object as the givenobject is being served to a requesting client in accordance with the oneor more content prefetching directives in the configuration file. 16.The apparatus as described in claim 15 wherein the one or more contentprefetching directives includes one of: a directive to enableprefetching, a directive to identify a content type for whichprefetching is enabled, a directive to identify a prefetching scanningmethod, a directive to indicate whether prefetching should be enabled ifthe proxy server connects to the origin server directly, a directive toindicate whether prefetching should be enabled if the given object wascached at the proxy server, a directive to manage prefetching of anon-cacheable content object, a directive indicating a maximum number ofcontent objects to prefetch within the given object, a directiveidentifying a set of one or more content object element types for whichprefetching is enabled, a directive to allow prefetching for a contentobject that has a domain that differs from the domain of the givenobject, a directive to allow recursive prefetching on at least onecontent object, and a directive to provide rate limiting to at least oneprefetch request.
 17. In an edge server of a content delivery networkthat is shared by a set of participating content providers, wherein agiven content provider has an associated origin server and identifiesgiven content for delivery, a method of content delivery, comprising:receiving a customer-specific, domain-specific configuration file thatincludes one or more prefetching directives, and at least one othercontent delivery directive; as a given object associated with a contentprovider domain is being served to a requesting client, scanning thegiven object if a prefetching status for the content provider domain hasbeen enabled as indicated by the prefetching directive in theconfiguration file; prefetching at least a first content objectassociated with the given object, wherein the first content object iscacheable and is prefetched from one of: the origin server, a parentedge server, and a disk associated with the edge server; and fetching asecond content object associated with the content provider domain asindicated by the other content delivery directive in the configurationfile.
 18. The method as described in claim 17 wherein the second contentobject is dynamic content and is fetched from the origin server.
 19. Themethod as described in claim 18 wherein the other content deliverydirective in the configuration file controls the edge server to obtainthe second content object via a path that includes at least one otheredge server in the content delivery network.
 20. The method as describedin claim 17 wherein the other content delivery directive in theconfiguration file is a directive to optimize a TCP connection parameterassociated with the edge server.